1. The Field of the Invention
The present invention relates to the field of device failure recovery for computer software. Specifically, the present invention relates to methods, systems, and computer program products for resource recovery from an untrusted region of computer executable instructions that permits continued execution of computer instructions in a trusted region without encountering potential inconsistencies introduced by recovering the resource from the untrusted region.
2. Background and Related Art
Computer display hardware is becoming increasing powerful. Although it has not always been the case, nearly all computer display hardware for graphical displays includes a graphics processor optimized for performing graphics instructions or commands. A graphics processor provides two primary benefits. First, because graphics instructions generally include a command (e.g., draw a polygon, draw a circle, etc.) with certain parameters (e.g., size, location, etc.) rather than information for drawing individual display pixels, less information needs to be transferred to the display hardware. Second, the graphics processor performs a significant amount of processing that otherwise would be performed by a computer's central processing unit (“CPU”).
Various layers of computer software typically are involved in controlling display hardware, including applications, operating systems, and device drivers. Device drivers generally implement abstract operating system calls for specific display hardware. Accordingly, an operating system uses the device driver for all hardware specific operations. In many cases, the interaction between the device driver and the display hardware is asynchronous, essentially meaning that the device driver asks the display hardware to perform some operation and then checks back later to see if the operation has been completed. Occasionally, a graphics processor will “hang” so that no commands are being processed.
When a graphics processor hangs, it appears as if the entire computer system hangs because no display updates occur. In some circumstances, however, the majority of the computer system, (e.g., applications, operating system, display, CPU, etc.) are all operating, but waiting for the graphics processor to complete a particular operation. The device driver is functioning—constantly asking if the graphics processor has completed a requested operation—but not performing any useful task.
One possible solution is to terminate the thread which is stuck in the driver. As suggested above, the rest of the computer system likely is functioning properly, but no display updates occur. However, terminating the stuck thread may cause more problems than it solves. In particular, terminating the thread may cause inconsistencies in the operating system. To appreciate why, it is helpful to understand that many operating systems provide at least two process modes: (i) a relatively less trusted and therefore more restricted user mode, and (ii) a relatively more trusted and therefore less restricted kernel mode.
Generally, application processes run within user mode so that the processes are isolated and cannot interfere with each other's resources. User processes switch to kernel mode when interacting with the operating system, such as when making system calls, generating an exception or fault, or when an interrupt occurs, etc. Processes running in kernel mode are privileged and have access to all computer resources (such as all available memory), without the restrictions that apply to user mode processes. When a graphics processor hangs, the process/thread executing the device driver is in kernel mode.
In many cases, a thread in kernel mode may have acquired resources, such as locks for exclusive use, mutexes and semaphores for synchronization, memory, etc. Furthermore, kernel mode processes tend to update sensitive memory structures that are expected to be consistent when an update is completed. For example, a kernel mode process may lock a resource, perform various updates to the resource that cumulatively leave the resource in a consistent state, and unlock the resource when finished. In arbitrarily terminating a kernel mode thread, locks may be left in place, resources may remain allocated, and resources that have not been fully updated may be left in an inconsistent state. Accordingly, methods, systems, and computer program products that allow for resource recovery that permit continued execution of computer instructions without encountering potential inconsistencies introduced by recovering the resource are desired.